1. Field of the Invention
The invention relates to apparatus and accompanying methods for use therein for implementing a secure, cost-effective, web-enabled, integrated, virtual office user environment, through a centralized server(s), through which a remotely stationed user can access typical office network-based applications, including, e.g., e-mail, file sharing and hosted thin-client application programs, through a remotely located network, e.g., WAN, connected web browser, as well as for remotely providing network monitoring and management capabilities. The present invention is particularly, though not exclusively, suited for use in small to medium size organizations which, for economic reasons, do not have adequate in-house computer support (technical and administrative) capabilities.
2. Description of the Prior Art
With laptop personal computers (PCs) having become rather ubiquitous over the last several years, individuals who are away from their office, typically desktop, PCs and hence not in communication with their office networks, because they are either traveling or are at home, often have a continuing need to gain access to those networks. Such access is required if, for no other reasons, than only for those users to transfer files between their laptop PCs and servers on these networks and/or access their network-based e-mail servers (both for receiving incoming and transmitting outgoing messages).
This need is not only shared by many individuals but also by organizations of widely varying size, from large organizations to very small businesses and other groups.
The art teaches various approaches to meet this need. However, they are all deficient in one respect or another. In that regard, none of these approaches offers an effective, integrated solution that readily provides all the functionality obtainable using an office network through one simple remote user interface, such as a web browser.
Specifically, one approach is to simply install appropriate conventional communications software in each client laptop PC and permit its user to access, through a dial-up telephone line, his(her) office network to gain access to the network server for file transfer and e-mail functionality. All application programs would reside on and locally execute on the client laptop PC. While this approach is quite simple, nevertheless it necessitates that each and every such application program be installed, configured and then maintained on that PC. Consequently, over time, this approach, particularly in view of the on-going support costs of the installed application programs, can become quite expensive.
Another approach involves using a traditional virtual private network (VPN) to provide wide area network (WAN) connectivity from a user's remote or home location to an office local area network (LAN). A VPN WAN connection implements a so-called OSI layer 2 extension or “conduit” of the office network itself between the LAN and the user's remote/home location. A remote client PC, connected through a VPN to an office LAN, locally appears on the LAN, as far as that user is concerned, as if that client PC were directly connected to it. In essence, for packets destined from the client PC to the LAN, a VPN connection therebetween involves, at a near end of the VPN connection, encapsulating outgoing OSI layer 3 packets at the client PC into layer 2 IP (Internet protocol) packets and transmitting those layer 2 packets over the VPN connection (in effect tunneling those layer 3 packets through the VPN connection), and subsequently, at a remote (LAN) end of the VPN connection, disassembling the layer 2 packets to yield the layer 3 packets and applying the resulting layer 3 packets onto the LAN for carriage to their ultimate destination, such as a network server. The opposite operation occurs in reverse for packets emanating from LAN, e.g., the server, and destined, over the VPN connection, to the remote client PC. Since the layer 2 packet tunneling is totally transparent to both the LAN and the client PC, advantageously the client PC can provide the same level of functionality to its user as if that PC were directly connected to the LAN.
Historically, a VPN connection required special, expensive VPN termination equipment located at each end of the connection, or required special client software to be installed and configured at the client machine. This equipment was rather expensive to acquire, and proved to be rather tedious to properly configure and hence costly to administer and maintain, particularly for those small to medium sized organizations that lacked adequate in-house technical support personnel.
In particular, at the remote client site, a so-called VPN terminator (also referred to as a “client-site VPN router”) was connected to a client PC to bi-directionally interface that PC to the VPN connection. This terminator provided layer 2 packet processing as well as appropriate packet encryption/decryption functionality. However, such a terminator, which included special-purpose software, was generally quite expensive to procure and needed to be installed and properly configured for its particular client PC—the latter entailing significant costs in both time and money. To mitigate the cost somewhat, various currently available PC operating systems (O/S's) now provide VPN support features, and, as an alternative, VPN vendors have built client VPN software that runs on the client machine and interacts with that vendors' own VPN server or with VPN servers from other vendors. Such client VPN software has been built to work with conventional PC O/S's such as Windows 98, Windows NT, Windows 2000, etc. However, PC O/S-based or client software based VPN support requires considerable packet processing (e.g., for packet encapsulation and disassembly, and cryptographic processing), which disadvantageously imposes a significant processing burden on the PC—though this burden may be acceptable for a home PC with a relatively light processing load, rather than a remote PC connected to an office network.
Furthermore, VPN services must be very secure. Unfortunately, until rather recently such PC O/S-based VPN support used a rather small key size, such as 40-bits, which generally does not provide sufficient security against third-party intrusion. While relatively new PC-based operating systems have become available that exhibit significantly increased VPN security, through use of triple DES and IPsec features—such as MICROSOFT® WINDOWS® 2000 O/S (“Windows 2000” is a trademark of the Microsoft Corporation of Redmond, Wash.), this support still presents a considerable processing load to the PC; hence, denigrating PC performance, specifically processing throughput.
Moreover, such PC operating systems, whether those exhibiting increased VPN security or not, still do not provide requisite reliability.
As such, to provide VPN connectivity with required levels of security and reliability without imposing an undue processing load on the client PC, use of a separate dedicated client-site VPN terminator—even in view of its expense—is still strongly favored in practice.
Not only is expensive, specialized VPN equipment required at the client site (or alternatives such as OS-based VPN support or client software packages, both with their accompanying problems, need to be used), but it is also necessary, to an even greater extent, at the LAN (central) site. At the LAN site, VPN support requires installation and configuration of an office-site VPN router. Office-site routers are considerably more expensive than client-site VPN routers for the simple reason that the processing circuitry in the former, which implements the necessary cryptographic and packet processing operations, is sized based on a number of users that need to be simultaneously supported. Each user is allocated a certain slice of the available processing capacity. Even if such a router is sized to support just a few simultaneous remote users on the LAN, its cost can easily amount to several thousands of dollars, with the cost rapidly escalating as user load and hence necessary processing capacity of the VPN router increased. Recently, server operating systems, such as the MICROSOFT® WINDOWS® 2000 server O/S, have become available that incorporate multi-user VPN support with sufficient security features; however, such support drains considerable processing resources from the server and still is insufficiently reliable. Moreover, if such a server O/S-based approach is used, counterpart client-site software, such as the Windows 2000 O/S, must be installed and properly configured on each client PC, which, if a large number of remote users exists, can be rather expensive and time consuming.
Therefore, in view of the relatively high cost involved, most small to medium sized organizations were and continue to be unable to afford the use of VPN connectivity, thus precluding themselves from providing secure remote office access to their internal networks and various business efficiencies and productivity increases that could have gained thereby.
A further, though totally different approach, evolved in the art for providing remote connectivity to an office LAN. This approach, predicated on an “application service provider” (ASP) model, involves installing specialized server software, such as “Metaframe” software available from Citrix Corporation, in the network server and an “ICA” client program in each client PC. Through the Metaframe program, the network server situated on the LAN would function as an ASP by hosting multiple virtual sessions of a given application program executing on the server, in effect implementing multiple virtual machines, to various different remotely located client PCs. Each remote client, running the ICA client program, would access, over, e.g., a WAN connection, a desired thin-client application hosted at the LAN-based server and establish a separate application session. The ICA client would communicate mouse clicks and keystrokes entered by a user stationed at the client PC, over the WAN connection, to the Metaframe program executing in the server which, in turn, would provide screen shots back to the client PC for local display to a user stationed thereat. This information would be carried between the client and server using an “ICA” protocol.
As PC manufacturers began equipping their PCs with client web browsers as standard issue software as well as users downloading such browsers for free from various software manufacturers, the Metaframe program evolved to permit remote browser-based web access, with the ICA client being replaced by the use of a resident client browser in the PC.
The concept of providing multiple virtual machines is also provided through “Windows Terminal Services” (WTS) software currently available from the Microsoft Corporation (“WINDOWS®” is a trademark of the Microsoft Corporation) for Windows NT 4 and Windows 2000 server operating systems, with client-server communication of screen shots, keystrokes and mouse clicks being carried to and from WTS using “RDP (‘Remote Desktop Protocol’ defined by Microsoft Corporation and based on the ANSI T.128 standard)”, rather than an “ICA” protocol. Again, WTS, like the Metaframe program, still carries a considerable processing burden.
Unfortunately, with this ASP-based approach, the client PC did not appear as if it were connected to the LAN. As such, while this approach did allow remote application execution, it did not accommodate remote access of other essential office network-based functionality, such as file sharing and e-mail. Hence, this approach was seen as being rather “one-sided”.
The art supplemented this ASP-based approach by incorporating a VPN (layer 2) connection between the LAN and client PC. This, in turn, provided added client functionality inasmuch as the client PC appeared as though it was on the remote LAN. However, this approach not only proved to be rather inconvenient to use but also, due to its VPN connectivity and for the reasons set forth above, rather expensive.
Specifically, a VPN server was connected to the LAN and a VPN router (or VPN terminator) was connected to each client PC, or each client PC used OS-based VPN support, or special client software had to be installed on each PC. The Metaframe program or WTS executed on the server which provided access, through a client browser or a special client application program, to a server-hosted virtual application session. By virtue of the VPN connection, the user at the client PC could remotely execute server-hosted thin-client applications, with the client PC appearing as if it were directly connected to the LAN. Unfortunately, this approach, being hampered by the constraints of the Metaframe software or WTS, only accommodated thin-client applications through the browser, and hence was just as “one sided”. No other network functionality, such as e-mail or shared file access, was accommodated through the browser; hence, this approach proved somewhat inconvenient to use. Moreover, the high cost of the associated VPN client-site and office-site servers principally dissuaded many small to medium size organizations from using this approach.
To off-load some of the processing burden from the LAN server running WTS, a two-tier approach recently appeared in the art through which a specialized processing system was inserted between the server and a WAN connection. This processor converted RDP packets associated with WTS into AIP packets (AIP is a proprietary protocol owned by Tarantella Inc. of Santa Cruz, Calif.) or to some other less bandwidth-intensive protocol and conducted client application communication (screen shots, keystrokes and mouse clicks) with the far-end client PC through either of the latter protocols. ICA provides similar bandwidth conserving functionality. Alternatively, communication in native RDP may be used instead. In any event, the client PC interacted with the processing system through either a specialized client application program or a web browser executing an appropriate JAVA applet (“JAVA” is a trademark of Sun Microsystems, Inc. of Palo Alto, Calif.). While this scheme relieved some of the load on the server, it still suffered the same deficiency as an ASP approach: it was not integrated and thus failed to provide through one single user interface, such as a browser, all the functionality which that user would have if his(her) client PC were directly connected to his(her) office LAN.
In view of the increasing costs of software acquisition, client installation and maintenance of client application programs, internally centralized ASP-based remote application hosting may well become an attractive alternative for business users.
However, adequate security remains a concern, particularly for small to medium size businesses that seek to implement an ASP-approach using the Win 2000 O/S or similar system. In that regard, WTS provides cryptography, though at a 168-bit level, through use of a symmetric key. While each RDP message from a network server to a remote client is sufficiently encrypted by WTS to preclude its brute-force cryptanalysis, shared symmetric keys are vulnerable to third party discovery for the simple reason that the secret key has to be distributed to the parties using it, and thus can be obtained by a malicious party. Since the Windows 2000 WTS approach does not involve the use of certificates, it is vulnerable to “man-in-the-middle” attacks from malicious parties that have obtained the symmetric key. In symmetric-key cryptography, both sides, here being the remote client PC and the server, utilize the same key. As such, if a third-party interloper, a so-called “man in the middle” that had previously obtained the symmetric key, were to intercept communications, that party through its computer, could pose as the server to the client machine, and as the client to the server machine. However, that party would thus be privy to all communications attempted between the client and the server, and thus have access to information that could be highly proprietary. That party could readily decrypt each message it received from one end and then alter the message contents as it saw fit, and transmit a modified message to the other end, thus potentially causing considerable mischief. Since WTS provides no effective protection to so-called “man in the middle” attacks, inasmuch as its symmetric key scheme does not involve the use of certificates and public keys cryptography, use of WTS under the WIN 2000 O/S is still not viewed by many organizations as offering a sufficiently attractive or secure solution to properly support such centralized thin-client application program hosting.
Therefore, a need exists in the art for a technique, specifically apparatus and methods for use therein, that provides secure, but integrated network functionality through a remote WAN connection between a remote client PC and a server based on an office LAN. Such a technique should provide all network functionality, including, e.g., thin-client application program hosting, file sharing and e-mail, through a single, commonly available user interface, such as a web browser, as if that client PC were connected directly to the LAN. The security should be such as to substantially eliminate potential “man in the middle” attacks or other such third-party intrusions. Furthermore, through such a technique, the client PC should appear as if it were directly connected to the LAN.
While such a technique could utilize a VPN connection, it should function with preferably far less costly alternatives, such as interacting directly with transport schemes such as DSL (digital subscriber line) or other relatively low-cost, high-speed digital access modalities. Also, such a technique should be remotely administered and supported, particularly when employed in those organizations which can not afford to maintain adequate in-house computer support capabilities.
Such a technique, were it to exist, would likely be very attractive to many organizations, including small and medium sized businesses: (a) to permit effective internal ASP-based (centralized) thin-client application program hosting for remote client connectivity, with resulting cost savings to those organizations in application procurement as well as through centralized administration and maintenance of those application programs, and (b) through its use, to yield increased efficiency and productivity by providing remote access for individual users to all their office network-based functionality.